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Abstract 


Gardiner, P., and C. Morgan, Data refinement of predicate transformers, Theoretical Computer 
Science 87 (1991) 143-162. 


Data refinement is the systematic substitution of one data type for another in a program. Usually, 
the new data type is more efficient than the old, but also more complex; the purpose of data 
refinement in that case is to make progress in a program design from more abstract to more 
concrete formulations. A particularly simple definition of data refinement is possible when 
programs are taken to be predicate transformers in the sense of Dijkstra. Central to the definition 
is a function taking abstract predicates to concrete ones, and that function, a generalisation of 
the abstraction function, therefore is a predicate transformer as well. Advantages of the approach 
are: proofs about data refinement are simplified; more general techniques of data refinement are 
suggested; and a style of program development is encouraged in which data refinements are 
calculated directly without proof obligation. 


1. Introduction 


In many situations it is simpler to describe the desired result of a task than to 
describe how a task should be performed. That is particularly true in computer 
science. Computer programs are very complex, both in their operation and in their 
representation of information. Yet the task a program performs is often simple to 
describe. 

More confidence in a program’s correctness can be gained by describing its 
intended task in a formal notation. Such specifications can then be used as a basis 
for a provably correct development of the program. The development can be 
conducted in small steps, thus allowing the unavoidable complexity of the final 
program to be introduced in manageable pieces. 
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The process, called refinement, by which specifications are transformed into 
programs has received much study in the past. In particular [6, 4, 2,9] have laid 
down much of the theory and have recognised two forms of refinement. Firstly 
algorithmic refinement, where one makes the way in which a program operates more 
explicit, usually introducing an algorithm where before there was just a statement 
of the desired result. And secondly data refinement, where one changes the structures 
for storing information, usually replacing some abstract structure that is easily 
understood by some more concrete structure that is more efficient. 

More recently the emphasis has turned towards providing a uniform theory of 
program development, in which specifications and programs have equal status. Such 
a theory is needed to provide the proper setting both for further theoretical work 
on refinement and for conducting refinement in practice. That goal has been achieved 
in [2,13,10,11] by extending Dijkstra’s language of guarded commands with a 
specification statement. The extended language, by encompassing both programs and 
specifications, reduces the process of modular program development to program 
transformation. Only algorithmic refinement is covered in [13, 10, 11]. In this paper 
we carry on in the same style to include data refinement, and thus give a more 
complete framework for software development. In [14], a similar extension is made. 

An important part of our approach is the use of predicate transformers, as in [4], 
which seem to have several advantages over relations, used in [7]. One is that 
predicate transformers can represent a form of program conjunction not represent- 
able in the relational model. That form of conjunction behaves well under data 
refinement, and can be used to simplify the application of data refinement to 
specifications. Also, since recursion can be re-expressed in terms of conjunction, 
that good behaviour allows reasoning about recursion without assuming bounded 
non-determinism, an unwanted assumption in a theory of programs which includes 
specifications. Probably the greatest advantage of using predicate transformers, 
however, is that the theoretical results are so easily applied in practice. In particular, 
we use a predicate transformer to represent the relationship between abstract and 
concrete states of data refinement, and that predicate transformer can be used to 
calculate directly the concrete program from the abstract program. The calculation 
maintains the algorithmic structure of the program and adds very little extra compli- 
cation. Moreover, such calculations do not have “applicability conditions”: no extra 
proof of correctness is necessary. 


2. Overview 


Throughout the paper predicate transformers are used to give meaning to program- 
ming and specification language constructs. In Section 3 we introduce the various 
operators and relations on predicate transformers that are needed for that purpose. 

Section 4 gives a short introduction to algorithmic refinement and its relationship 
to specification. 
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In Section 5 data refinement is introduced as a transformation on local blocks of 
a program. It is expressed using a predicate transformer that takes predicates on 
the abstract state into predicates on the concrete state. It is proven that data 
refinement applied to a local block has the effect of algorithmically refining the 
whole program. 

In Section 6 Dijkstra’s language of guarded commands is extended with constructs 
for specification. The new constructs are given meaning as predicate transformers, 
and so have equal status with the other constructs of Dijkstra’s language. It is shown 
that one of these constructs, which we call program conjunction, can be used to 
formalize the use of logical constants in Hoare-style developments. We also show 
how Dijkstra’s language can be broken up into smaller units than usual. 

In section 7 we prove that data refinement distributes through each construct of 
the development language. The proofs justify the application of data refinement by 
parts, retaining the existing algorithmic structure. 

In Section 8 a simple method for calculating data refinements of specifications 
is presented. The calculation is performed by applying a predicate transformer which 
takes abstract predicates into concrete predicates. It is proven that the calculation 
yields the most general concrete program. 

In Section 9 we discuss the conditions under which fragments of a program can 
be left unchanged during data refinement. That is important when programs are 
structured into abstract data types. The conditions justify the use of abstract data 
types to delineate the scope of data refinement. 

In Section 10 a particular predicate transformer for performing data refinement 
is presented. It has a very simple syntactic form, and is easily applied to the text 
of a program. 

Finally, in Section 11 we give an example of our method applied to a simple 
program. 


3. Predicate transformers 


Following [4], we model programs as functions taking predicates to predicates. 
We intentionally blur the distinction between predicates and the sets of states 
satisfying them, and therefore we think also of programs as taking sets of (final) 
states of (initial) states. In any case, for program P and predicate w, called the 
postcondition, the application of P to w& is written Py and yields a predicate ¢, 
called the weakest precondition of y with respect to P. We say that P transforms w 
into @. The predicate ¢ is the weakest one whose truth initially guarantees proper 
termination of P in a state satisfying & finally. The expression Py can also be read 
simply as “P establishes ws’. 

The purpose of predicates in the model is to specify sets of states. For that reason, 
when giving the meaning of a program as a predicate transformer we will consider 
only predicates whose free variables are drawn from the program’s set of state 
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variables. We will call the set of state variables the program’s alphabet (written aP), 
and call the predicates whose free variables are drawn from a given set of variables 
x “the predicates on x”. Thus, a predicate transformer P can be defined by giving 
the value of Pw for all predicates y on aP. Of course, we have to take care not to 
apply predicate transformers outside their domains. 

For clarity, we will sometimes need to distinguish between program texts and 
their corresponding predicate transformers, writing Į T] for the predicate transformer 
denoted by the program text T. 

We define an order < on predicates as follows: 


b<¥ iff E> ¥. 
The order < permits least upper and greatest lower bounds of collections of 
predicates ¢; for which we write, respectively V; 6; and A; ¢;. Also the order has 
a top and bottom, T and L, which correspond to true and false. 
The order on predicates is promoted to predicate transformers in the usual way; 
for predicate transformers P and Q such that aP = aQ, 
PQ iff forall predicates 6 on aP, Pd <Q¢. 


The promoted order has least upper and greatest lower bounds as well as a top and 
bottom element, and they satisfy the following equations: 


(Lin)o=vire, 


(m r)o=A Pa), 


ig=i, 
TOH=T. 


All the predicate transformers P we consider are monotonic: for any predicates ¢ 
and y, ġ = y implies Pd < Py. 


4. Algorithmic refinement of predicate transformers 


In general, one mechanism is refined by another exactly when every specification 
satisfied by the first is also satisfied by the second. For predicate transformers we 
take specifications and satisfaction as follows: a specification is a pair of predicates 
comprising the initial assumptions pre and the final requirement post; and a program 
P satisfies the specification exactly when 


pre => P post. 


It is now easy to show that P is refined by Q exactly when PE Q. 

The view of specifications distinguishes them from programs. In Section 6, 
however, we map specifications into the domain of predicate transformers and thus 
drop the distinction. 
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5. Data refinement of predicate transformers 


During algorithmic refinement, local variables may be introduced. Assignments 
to local variables do not play a part in the external behaviour of a program. Thus 
the way local data is stored can be altered without affecting the external properties 
of a program. Such alterations are called data refinements. 

It is common practice for the parts of a program that refer to certain local variables 
to be named and collected together to form an abstract data type [5]. In Section 9 
we discuss data refinement in the context of abstract data types, but here we prefer 
to work with the most simple structuring mechanism that permits data refinement 
(i.e., the local declaration). 

The following syntax is used to hide (make local) a list of variables x: 


[var x| Ie PJ]. 


The predicate J states the initialisation of x, and P is the program within which 
the variables x may be used. The construct is used only if the alphabet of P contains 
x. The alphabet of the result is that of P with x removed. The meaning of the 
construct is as follows: for any predicate w on (aP—x), 


[|[var x|I° P]]y (Wx eI >[P]y). 


The definition states that a program with a local variable establishes a predicate if 
and only if execution of the body, with any initial value of the local variable, 
establishes the predicate. 

We now define data refinement. Let us suppose we wish to replace the list of 
variables a (the abstract variables) in 


[var a|I © P]| 


by some other list of variables c (the concrete variables), and let the variables of 
aP, other than a, be g (the global variables). We choose any predicate transformer 
rep that takes predicates on the variables a, g to predicates on the variables c, g. 
Then for programs P and P’, we write P < P’ to mean that P is data-refined by P”. 


Definition 5.1. P < P’ iff rep ° PE P’° rep, where the operator ° is functional composi- 
tion (of predicate transformers). 


We will see that for data refinement to be well behaved, we must restrict our 
choice for rep. We choose rep satisfying the following two properties: 


rep is monotonic: (Ya » ġ > 4) => (Vee repo => rep); 
rep is v -distributive: rep (v d) =V (rep ġi;). 


Note that strictness is a special case of v-distribution (i.e., rep 1 =). Note also 
that our monotonicity is stronger than the usual. Further properties that follow from 
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those just defined are proven below. In the proofs that follow and elsewhere we 
will make use of the fact that the two lists of variables a and g are, by definition, 
disjoint and so the variables a do not occur free in the predicates on g. 


Lemma 5.2. If ¢ is a predicate on g, then rep ġ = 9. 


Proof 
ad > (Varp >L) since a is not free in ¢, 


mae => (rep ġ => rep L) monotonicity of rep, 


ad => (repo => L) strictness of rep, 
1¢ > repo predicate calculus, 
repd=>o¢ predicate calculus. E 


Lemma 5.3. If ¢ is a predicate on a, g, and y is a predicate on g, then 
(repp)n y= reple n y). 
Proof 
y => (Vaed > Gab) since a is not free in w, 
y => (repd = rep(@rw)) monotonicity of rep, 
(rep d) nw => rep(draw) predicate calculus. o 
In subsequent sections we will discuss a particularly convenient choice for rep, 
and will show how to calculate suitable P’. For now, we give the fundamental 
theorem of data refinement. 
Theorem 5.4. If for suitable rep (as defined above) we have shown that P < P', then 


[var a|J © P]|<|[var c|rep I P’]|. 


Proof. Let y be any predicate on g; then 
[l[var a|I ° P][]y 
=(Vael => [P]y) semantics, 
<(VcerepI = rep[P]y) monotonicity of rep, 
<(VcerepI = [P']rep y) hypothesis, 
<(VcerepI = [P']y) Lemma 5.2 and monotonicity of P’, 


=[|[var c|rep I ° P’]|]v semantics. O 
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6. The development language 


The development language is Dijkstra’s language of guarded commands with 
several extensions. The extensions are to provide a language in which programs 
and specifications have equal status. Such a language is necessary for the uniform 
presentation and use of refinement. 

All of the predicate transformers P which can be described by Dijkstra’s original 
language satisfy the following properties: 
© strictness PL= L; 

è monotonicity ġ = implies Po < Pw; 

è a-distributivity P(N; yi) = A; (Ph;), for any non-empty family {y,};; 

© continuity P(V; Yi) = V: (Pu), for any chain {y;};. 

We will see that some of these properties fail in our extended language. 


6.1. Extensions 


6.1.1. Local variable declaration 

The first extension was given in Section 5; the introduction of local variables 
[var x|7 © P]]. It preserves monotonicity and -distributivity, but |[var x| ° P]| is 
not strict for any P, and |[var n|n €N m:= n]| is not continuous, although m := n is. 


6.1.2. Specification 

The second extension is the specification. It includes a pair of predicates, as in 
Section 4, but here it is added to the development language and given the same 
status as a programming construct. Specifications are written x: [pre, post], where 
x is a list of the variables that are allowed to change during its execution (pre and 
post are as in Section 4). Specifications are defined as follows: 


Definition 6.1. [x: [pre, post]]y < pre a (Wx © post => y). 


The definition states that x: [pre, post] will establish y if and only if it is executed 
from a state in which pre is satisfied and in which values of x that satisfy post also 
satisfy w. The specifications of the development language relate to the specifications 
of Section 4 as follows: a program P alters only the variables x and satisfies the 
specification consisting of predicates pre and post if and only if 


x: [pre, post]& P. 


Specifications are monotonic and a-distributive, but x:[T, L] is not strict, and 
x:[T, T] is not continuous (take any chain {,}; with V; y; =T but y; # T for any i). 
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6.1.3. Program conjunction 
The third extension is conjunction of programs, written $ i P, for any family {P;}; 
of programs. Its meaning is given as follows 


Definition 6.2. [; P;] 2|]; [P]. 


Thus the conjunction of a family of programs refines every member of the family, 
and is the most non-deterministic program that does so. Conjunction preserves 
strictness, monotonicity, and continuity, but not A-distributivity: consider 


[x: [T, y] $x: [T, aI a ay) 


for some w not equal to L or T. 

Conjunction is an important counterpart of the specification. The specification 
alone does not allow a relation to be set up between the initial and final states. A 
similar problem occurs when using Hoare Logic. There, the problem is solved by 
introducing names for initial values. For example, one might specify that a program 
P increments the variable n by writing 


{n=N} P{n=N+}}, 


using N to denote the initial value of n. 

Names such as N are called logical constants. By convention, they are written in 
upper case and must not appear in the final program. Since one is required to find 
P without knowledge of the value of N, such P will satisfy the specification for 
every value. 

Those conventions do not work for our specifications, which are treated as 
programs in their own right and typically appear as fragments of larger programs. 
For us, n: [n= N, n= N+1] is a program with a free variable N. What we need is 
a program that refines n: [n = N, n= N +1] for every value of N. That is where we 
use program conjunction, writing 


tna: [n=N,n=N+1], 
N 


which is the most non-deterministic such program. A simple calculation confirms that 


n:[n=N,n=N+1] = ni=n+1. 
N 


Another reason we use the combination of specification and conjunction, other than 
its relation to logical constants, is that it permits a particularly simple method of 
calculating data refinements. We will return to data refinement of specifications in 
Section 8. 

That completes the extension of Dijkstra’s language. We can now see that the 
only property retained from the original language is monotonicity: each of the other 
properties is violated by at least one of the program constructs. 
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The loss of these properties has no practical disadvantages for us, since we do 
not prove programs correct by calculating weakest preconditions. Instead, we 
develop programs stepwise using refinement rules of the form PC Q, where P is a 
specification and Q is usually a construct such as if- -fi surrounding further 
specifications. A development calculus consisting of rules of that form is presented 
in [11, 13]. 

The aim of development is to arrive at a program, written entirely in Dijkstra’s 
original language — the executable subset of our development language. Since every 
program of that language is strict, the loss of strictness for the general language has 
some significance. It implies that unimplementable programs can arise, and that 
developments can run into dead ends. That possibility can be guarded against, if 
one wishes, by checking the implementability of each new specification that arises 
in a development, that is by checking 


pre => (Ax ® post). 


However, one is not required to perform those checks. Any development that yields 
an implementation is valid, and the fact that the development calculus does not 
have the checks built in makes it far simpler than it would be otherwise. 


6.2. Generalizations 


Having accepted the loss of strictness, continuity and a-distributivity, we are able 
to make other generalizations of the language. Choice and guarding need not be 
restricted to use within the do: > -od and if - - - fi constructs. They can instead be 
defined as language constructs in their own right. 


Definition 6.3 (Choice). For any family {P;} of programs we define their choice as 
follows: 


10 s] £ PV Es]. 


Choice preserves monotonicity and ^-distributivity, but the empty choice is not 
strict and Jne nar M:= N is not continuous. 


Definition 6.4 (Guarding). For predicate G and program P, we define the guarded 
command G > P as follows: 


[G>P]y 4 G > (Ply. 


Guarding pi.serves monotonicity, A-distributivity and continuity, but L> P is 
not strict for any P. 
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Definition 6.5 (Recursion). We must consider program contexts, which are program 
structures into which program fragments can be embedded. If € is a program context 
and P a program, then €(P) is a program also. We write uX * €(X), where X is 
a program variable and € is a context, to mean the recursive program consisting 
of @, with X marking the recursive calls. We extend the denotation function | ] in 
the obvious way, so that [€] yields a function from predicate transformers to 
predicate transformers. Thus we have 


[uX e €(X)] = fix] ¢] 


where fix takes the least fixed point of a function (from predicate transformers to 
predicate transformers in this case). A least fixed point exists, because each construct 
of the development language is monotonic with respect to the refinement relation, 
and so contexts are monotonic also. 


Recursion preserves monotonicity, strictness, A-distributivity and continuity. 
With these definitions, we can if we wish define the conventional if: - - fi and 
do : -- od constructs as appropriate combinations. We have the following. 


Definition 6.6 (Alternation) 
if G,> P, 
1G, > Pn 
fi 


is an abbreviation for 


(1 G;> P.) l -(v a.) > abort 


i=] 


Definition 6.7 (Iteration) 
do G, > P; 
l 
1G, > P,, 
od 


is an abbreviation for 


(ux ° (å a>r; x)in(y G,) > skip). 


Data refinement of predicate transformers 153 
7. Distribution of data refinement 


After Theorem 5.4, the most important property of data refinement is that it 
distributes through the algorithmic constructs of our development language. Only 
then can one carry over the algorithmic structure of the abstract program onto the 
concrete program. We prove distribution for each construct below. 


Lemma 7.1 (Sequential composition). If P< P’ and Q<Q' then P, Q< P'; Q’. 
Proof 
rep ° P; Q] 
=rep° [P] - [Q] semantics, 
c[P']° repe [Q] hypothesis, 
c[P']-[Q]e° rep hypothesis and monotonicity of P’, 


=[P’; Q’]° rep semantics. = 


Lemma 7.2 (Skip) skip < skip. 


Proof 
rep ° [skip] 
=rep° Id semantics, 
= rep property of Id, 
= [de rep property of Id, 
= [skip] ° rep semantics. o 


Lemma 7.3 (Abort). abort < abort. 


Proof 
rep © [abort] 
=repe L semantics, 
=L strictness of rep, 
=o rep property of L, 
=[abort]° rep semantics. o 


Lemma 7.4 (Guarding). To deal with guarded commands we will need another function 
from abstract predicates to concrete predicates. 


rep & (rep ay). 


We then have the following result for guarded commands. If P< P' then (G> P)< 
((rep G)> P’). 
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Proof 
rep[G > Ply 
=rep(G => [P]y) semantics, 
= rep(nGv[P]) predicate calculus, 


= (rep nG) v (rep Pl’) v -distributivity of rep, 
=~(rep G) v (rep[ P] ¥) definition of rep, 
=(rep G') = (rep[P]¥) predicate calculus, 
<(rep G) = ([P'] rep) hypothesis, 

=[(rep G)> P’] rep y semantics. o 


Lemma 7.5 (Choice). If for each i, P,< P;, then ], P: <f; Pi. 


[oe 


= rep ° (r (71) semantics, 


Proof 


c [ |(rep °[ PJ) monotonicity of rep, 


= [ Pi] e rep) hypothesis, 
= (rua) o rep property of M, 
= | OP 1] o rep semantics. 


Lemma 7.6 (Conjunction). If for each i, P,< P;, then £;P,< x; P; 


[ta] 


= rep ° (U[P.]) semanics, 


Proof 


=|_|(repe[P,]) v-distributivity of rep, 
cL _\([Pi]° rep) hypothesis, 
=(|[P;])° rep property of U, 


= E Pi orep semantics. o 
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Lemma 7.7 (Recursion). We first promote data refinement to program contexts: we 
say that € < ©’ exactly when for all pairs of programs P and P' such that P x P’, we 
have €(P)< €'(P’) as well. The result for recursion is then as follows: 


If ©<@", then (uX © €(X))< (uX © $(X)). 


Proof. The Limit Theorem (as generalized by Hitchcock and Park) asserts that, for 
monotonic F, there exists an ordinal A such that fix F = F* 1, where 


F°X =X, 
F°"'X = F(F*X), 
F*X = || (F®X). 


B<a 
Hence, it is sufficient to prove [¢]*1<[@‘]’1 for all A. That can be proven by 
induction. The base case follows from Lemma 7.3, the step case follows from € < €’ 
and the limit case follows from Lemma 7.6. O 


8. Data refinement of specifications 


In the preceding section, we showed that data refinement can be performed 
piecewise (a term we borrow from [14]), thus maintaining the algorithmic structure 
of a program. We now consider the pieces lying within the structure. 

There are two constructs to consider, the specification and the assignment. In 
fact, we can ignore the assignment statement since it is readily transformed into a 
simple specification. The following theorem provides a method for calculating the 
result of applying data refinement to a specification. 

Again, we write a for the list of abstract variables, c for the list of concrete 
variables, g for the remaining (global) variables and rep for the representation 
predicate transformer. 


Theorem 8.1. g, a: [pre, post] g, c: [rep pre, rep post]. 


Proof. Let y be any predicate on g, a; then 


rep|g, a: [ pre, post |W 


=rep(pre 1(Wg,a® post => w)) semantics, 
< (rep pre), rep(Wg,a* post => w) monotonicity of rep, 
< (rep pre) \(Wg,a* post => 4) Lemma 5.2, 


< (rep pre) a (Yg, c * rep post => repy) monotonicity of rep, 


=[g, c: [rep pre, rep post]lrep y semantics. o 
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Data refinement may partly resolve the non-determinism exhibited by the abstract 
program. We would like our calculating of data refinements to leave as much choice 
as possible for later algorithmic refinement steps. Thus we would like the calculation 
to produce the concrete program that is least in the refinement ordering. That is 
confirmed by the following theorem. 


Theorem 8.2. If g, a: [pre, post|< P, then 
g, c:[rep pre, rep post|& P. 


Proof. Let y be any predicate on g, c; then 


Ig, c: [rep pre, rep post} 
= (rep pre) a (Yg, c Ħ rep post => w) semantics, 


properties of v, 


<(rep pre) A (vs a* post => x) 
Vge,c®*repx=y 


< rep (pre A (vs, a* post => V x)) Lemma 5.3, 


Vag,c 9 repx => y 


= r(t a: [pre, post]] V x) semantics, 


Vg,c * repx => y 


<P (rep V x) hypothesis, 


Yg,c 9 repx=>Ņ 


= p( V rep x) v-distributivity of rep, 
Yg,c ° rep x= y 
< Py properties of v and 
monotonicity of P. 


Theorem 8.1 generalizes so that g can be any subset of the global variables, but 
then it is not necessarily the most non-deterministic concrete program that is 
calculated. 


9. Abstract data types 


So far we have been considering the application of data refinement to the whole 
of a local block. However, when a block is structured using abstract data types it 
is broken up and the parts become separated. The parts that refer to the local 
variables are collected together to form the abstract data type, leaving in place the 
parts that make no mention of the local variables. 

With that type of structuring it is essential that we are able to apply data refinement 
to the code fragments that make up the abstract data type, without having to consider 
the other parts of the local block. Even when a program is not structured in that 
way, it is still convenient to be able to ignore fragments of code that do not mention 
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the variables being refined. Thus we need to show that P < P holds for all programs 
P which do not refer to abstract variables. 

Most constructs of the development language do not introduce references to 
variables, so we need consider only guards and specifications. For guards, the proof 
is trivial, but for specifications, a further property of rep is required. 


Definition 9.1. rep is local if it maps predicates on a into predicates on c. 


Hence, if rep is local and g does not occur free in y, then g does not occur free 
in rep W. From that property of rep, the desired result for specifications follows. First 
we prove a lemma. 

Lemma 9.2. If rep is local, then 
rep(Wg ° Y) < (Yg ° rep y). 
Proof. 
(Vgew) > 4 predicate calculus, 
rep(Vgew) => repy monotonicity of rep, 
rep(Wgew) => (Vge repy) g not free in rep(Vg ¢ y) 
by locality. o 
Theorem 9.3. If rep is local and the variables a do not occur free in pre and post, then 
g: [pre, post] < g: [pre, post]. 
Proof. Let y be any predicate on g, a; then 
rep|g: [pre, post )]y 


=rep(pre n (Ng Ħ post => w)) semantics, 

< (rep pre) a rep(Wg ° post => w) monotonicity of rep, 
<prenrep(Vg * post => w) Lemma 5.2, 

< pre a (Yg ° rep(post = y)) Lemma 9.2, 

= pre a (Ng Ħ° rep(post v w)) predicate calculus, 

= pre n(Wg © rep(mpost) v rep y) v -distributivity of rep, 
= pre a (Ng © post v rep Y) Lemma 5.2, 

= pre a (Yg ° post => rep) predicate calculus, 
=[g: [pre, post]]rep y semantics. o 


10. Data refinement in practice 


So far we have given no indication as to how one chooses a suitable representation 
transformer rep. In fact, there may be many classes of program transformation that 
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can be supported by the theory of the preceding sections. We can, though, cite one 
example that proves very useful in practice. The definition of rep given below 
provides the same form of data refinement as that in [2, 5, 14] and also, under the 
name of downward simulation, in [8]. 

When performing data refinement, one always intends that the abstract, concrete 
and global states should correspond in some way. The correspondence can be 
expressed as a predicate over the three sets of state variables. From such a predicate 
(I, say) the representation transformer can be defined as follows: 


repo 2 (daelIad). 


If is easy to verify the properties required for data refinement (i.e., monotonicity 
and v-distributivity). If I does not refer to the global variables then rep also has 
the property required for applying data refinement to abstract data types (i.e., 
locality). 

rep also has a simple form: 


rep p=(Wael => @). 


With our choice of rep, we can see how easily data refinement can be performed 
by calculation. The two simple transformers, rep and rep can be applied directly to 
the predicates of any abstract program to calculate a concrete refinement. In the 
abstract program all the pre and post conditions of specifications are replaced by 
their image under rep and the guards by their image under rep, thus leaving the 
algorithmic structure unchanged. The result is guaranteed correct by the theorems 
of the previous sections. 


11. Example 


A typical development would alternate between algorithmic and data refinement. 
For this example, we will consider a development in which some algorithmic 
refinement has already occurred, thus producing the following program: 


l[var bJb={ }* 


$b: [b= B, b= Bu {e}] 
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Only the fragments that refer to the local variable b have been displayed. The 
variable b holds a set of natural numbers, and is initially empty. The first specification 
describes the addition, to the set, of an element e. The second describes the setting 
of the variable n to the maximum of the set. 

The data refinement we wish to conduct is that of replacing the set b by a number 
m that records the maximum of the set. The relationship between the two variables 
is 

m = max b. 
Hence the representation transformer is defined as follows: 


repy 2 (ab ° m=maxbn y). 


We can apply the transformer directly to the abstract program, and thus produce 
the concrete program: 


var m|(36- bia )- 


m=max b 


b=B 
b=B 
n,m (20 ), dben=max B 
B m=max b 
m=max b 


Jl. 
Using the predicate calculus (one-point law), that simplifies to 


|[var m|m = max{ }e 


t m: [m = max B, m = max(Bv {e})] 


Jl. 
The initialization further simplifies to m = 0, and the first specification simplifies to 


m: [m= max B, m = max{max B, e}]. 
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Now algorithmic refinement can continue. We can apply the assignment introduction 
rule [11], which asserts that if pre => post[x\E], then 
x: [pre, post] E x= E, 


where post[x\E] means the result of substituting E for x in post. Hence we can 
refine the first specification to m := max{m, e}. 

The same refinement rule can be applied to the second specification to produce 
the assignment n ‘= m. Lastly, since the logical constant B is no longer referred to, 
the program conjunctions can be dropped, leaving us with the following program: 


[var m|m=0 ° 


m = max{m, e} 


x 
{I 
3 


Jl. 


12. Conclusions 


We have presented the familiar technique of data refinement in the context of 
predicate transformers. In doing so we have drawn on other recent work in program 
development: the factoring of Dijkstra’s language into smaller pieces (Definitions 
6.6 and 6.7); the use of recursion in practice rather than iteration as the basis for 
unbounded computations in Dijkstra’s language [3]; and the mixing of specification 
and program [2, 13, 10, 11]. In Definition 6.2 we give a further factorization: with 
program conjunction, the technique of “logical” constants is formalized. All of that 
comes together to promote a style of program design in which steps are made by 
calculation rather than via proof obligations. 

It is clear, though, that proof cannot be avoided altogether! In practice, the 
necessary truths of predicate calculus are drawn on when strengthening postcondi- 
tions and weakening preconditions — and virtually nowhere else. In that respect 
perhaps the proofs have moved rather than disappeared. Their confinement though 
makes the other rules easier to apply in practice. Certainly they are easier to 
remember: the formulation of data refinement in Theorem 8.1 is simpler than any 
other of which we are aware. 

Using predicate transformers as a model, rather than the relations of [8], has 
several advantages. One is that the dependence on continuity is more easily broken. 
This allowed us to extend the work of [8] so that it applies to a language that 
includes constructs for specification as well as programming. Another advantage is 
the ease with which the theoretical results are applied in practice. Both those 
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advantages are related to program conjunction, which cannot be represented in the 
relational model. Conjunction simplifies the expression of specifications in our 
language; and that, in turn, permits our very simple method of data refinement 
calculation. In contrast, the method of calculation in [8], although theoretically 
simple, gives rise to very large and unwieldy expressions in practice. 

Our relaxing of Dijkstra’s “healthiness” conditions has left us only with monoton- 
icity: continuity, strictness, and a-distributivity are gone. That is similar to [13], 
where continuity and strictness are dropped so that the guard and choice symbols 
can be given meaning as operators in their own right. We too proposed that in [10], 
but have taken the process further, dropping also a-distributivity, so that we can 
define the conjunction operator which is the key to simplifying the calculation of 
data refinements. 

Our results are potentially more general than those of [14], since we recognise 
how the abstraction condition is itself applied as a predicate transformer, and base 
all our proofs on three properties of it. By doing that we make the structure of the 
proofs more explicit, and we leave open the possibility of finding other predicate 
transformers with those properties which can, therefore, also be used for data 
refinement. 

We also prove results that [14] does not. Theorem 5.4 forms the important link 
between data refinement of local variables and operational refinement. Theorem 8.2 
shows that our method of calculation yields the weakest program that is a data 
refinement of the original and thus that no loss of choice is incurred by calculation. 
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